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Abstract 

In  IEEE  802.  lib  network  testbeds,  we  examine  the  drawbacks  of 
estimating  unicast  link  properties  via  those  of  broadcast  packets. 
To  redress  these  shortcomings,  we  design  a  beacon-free  routing 
protocol  Learn  on  the  Fly  (LOF).  It  chooses  routes  without  as¬ 
suming  geographic  uniformity  by  way  of  a  locally  measurable 
metric  ELD,  the  expected  MAC  latency  per  unit-distance  toward 
the  destination;  it  estimates  link  quality  solely  based  on  data  traf¬ 
fic  without  employing  beacons.  Using  a  realistic  sensor  network 
traffic  trace  and  an  802.11b  testbed  of  195  Stargates,  we  exper¬ 
imentally  compare  the  performance  of  LOF  with  that  of  exist¬ 
ing  protocols,  represented  by  the  geography-unaware  ETX  and 
the  geography-based  PRD.  We  find  that  LOF  reduces  end-to-end 
MAC  latency  by  a  factor  of  3,  enhances  energy  efficiency  by  a 
factor  up  to  2.37,  and  improves  route  stability  by  2  orders  of 
magnitude. 

Keywords — experiment-based  design  and  analysis,  bursty  convergecast, 
beacon-free  geographic  routing,  data-driven  link  quality  estimation,  MAC 
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1  Introduction 

As  the  quality  of  wireless  links,  for  instance,  packet  delivery  rate, 
varies  both  temporally  and  spatially  in  a  complex  manner  [6,  17, 
23],  estimating  link  quality  is  an  important  aspect  of  routing  in 
wireless  networks.  Existing  routing  protocols  [8,  9,  10,  19,  21] 
exchange  broadcast  beacons  between  peers  for  link  quality  esti¬ 
mation.  Nevertheless,  link  quality  for  broadcast  beacons  differs 
significantly  from  that  for  unicast  data,  because  broadcast  bea¬ 
cons  and  unicast  data  differ  in  packet  size,  transmission  rate,  and 
coordination  method  at  the  media-access-control  (MAC)  layer 
[7,  18].  Therefore,  link  quality  estimated  using  periodic  beacon 
exchange  may  not  accurately  apply  for  unicast  data,  which  can 
negatively  impact  the  performance  of  routing  protocols. 

In  wireless  sensor  networks,  a  typical  application  is  to  monitor 
an  environment  (be  it  an  agricultural  field  or  a  classified  area)  for 
events  of  interest  to  the  users.  Usually,  the  events  are  rare.  Yet 
when  an  event  occurs,  a  large  burst  of  data  packets  is  often  gen¬ 
erated  that  needs  to  be  routed  reliably  and  in  real-time  to  a  base 
station  [22],  In  this  context,  even  if  there  were  no  discrepancy 
between  the  actual  and  the  estimated  link  quality  using  periodic 
beacon  exchange,  the  estimate  would  tend  to  reflect  link  quality 
in  the  absence,  rather  than  in  the  presence,  of  bursty  data  traffic. 
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This  is  because:  First,  link  quality  changes  significantly  when 
traffic  pattern  changes  (as  we  will  show  in  Section  2.2.2).  Sec¬ 
ond,  link  quality  estimation  takes  time  to  converge,  yet  different 
bursts  of  data  traffic  are  well  separated  in  time,  and  each  burst 
lasts  only  for  a  short  period. 

Beacon-based  estimation  of  link  quality  is  not  only  limited  in 
reflecting  the  reality,  it  is  also  inefficient  in  energy  usage.  In 
existing  routing  protocols  that  use  link  quality  estimation,  bea¬ 
cons  are  exchanged  periodically.  Therefore,  energy  is  consumed 
unnecessarily  for  the  periodic  beaconing  when  there  is  no  data 
traffic.  This  is  especially  true  if  the  events  of  interest  are  infre¬ 
quent  enough  that  there  is  no  data  traffic  in  the  network  most  of 
the  time  [22] . 

To  deal  with  the  drawbacks  of  beacon-based  link  quality  es¬ 
timation  and  to  avoid  unnecessary  beaconing,  new  mechanisms 
for  link  estimation  and  routing  are  desired. 

Contributions  of  the  paper.  Using  outdoor  and  indoor  testbeds 
of  802. 1  lb  networks,  we  study  the  impact  of  environment,  packet 
type,  packet  size,  and  interference  pattern  on  the  quality  of  wire¬ 
less  links.  The  results  show  that  the  assumptions  of  beacon- 
based  routing  do  not  hold  well,  and  that  we  need  to  directly  esti¬ 
mate  unicast  link  quality  without  using  broadcast  beacons. 

Fortunately,  we  find  that  geography  and  the  DATA-ACK  hand¬ 
shake  (available  in  the  802.11b  MAC)  make  beacon-free  rout¬ 
ing  possible  in  terms  of  information  diffusion  and  beacon-free 
link  quality  estimation.  Using  geography  and  MAC-layer  trans¬ 
mission  latency  (simply  referred  to  as  MAC  latency  hereafter), 
we  define  a  routing  metric  ELD,  the  expected  MAC  latency  per 
unit-distance  toward  the  destination.  ELD  is  locally  measurable 
and  does  not  assume  geographic  uniformity  —  that  the  hops  in 
any  route  have  approximately  the  same  geographic  length  .  Via 
experiment-based  analysis,  we  find  that  MAC  latency  has  a  log¬ 
normal  distribution,  and  that  the  sample  size  required  for  ELD- 
based  routing  is  relatively  small  (e.g.,  the  80-percentile  is  only 
8).  We  also  mathematically  show  that  MAC  latency  is  a  good 
indicator  of  energy  consumption  in  packet  transmission. 

To  enable  beacon-free  routing,  we  modify  the  Linux  kernel 
and  the  WLAN  driver  hostap  [3]  to  exfiltrate  the  MAC  latency 
for  each  packet  transmission,  which  is  not  available  in  existing 
systems.  The  exfiltration  of  MAC  latency  is  reliable  in  the  sense 
that  it  deals  with  the  loss  of  MAC  feedback  at  places  such  as 
netlink  sockets  and  IP  transmission  control. 

Building  upon  the  capability  of  reliably  fetching  MAC  latency 
for  each  packet  transmission,  we  design  a  routing  protocol  Learn 
on  the  Fly  (LOF)  which  implements  the  ELD  metric  in  a  beacon- 
free  manner.  In  LOF,  control  packets  are  used  only  rarely,  for 
instance,  during  the  node  boot-up.  Upon  booting  up,  a  node  ini- 
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tializes  its  routing  engine  by  taking  a  few  (e.g.,  8)  samples  on  the 
MAC  latency  to  each  of  its  neighbors;  then  the  node  adapts  its 
routing  decision  solely  based  on  the  MAC  latency  for  data  trans¬ 
mission,  without  using  any  control  packet.  To  deal  with  temporal 
variations  in  link  quality  and  possible  imperfection  in  initializ¬ 
ing  its  routing  engine,  the  node  switches  its  next-hop  forwarder 
to  another  neighbor  at  controlled  frequencies  with  a  probability 
that  this  neighbor  is  actually  the  best  forwarder. 

Using  an  event  traffic  trace  from  the  field  sensor  network  of 
ExScal  [5],  we  experimentally  evaluate  the  design  and  the  per¬ 
formance  of  LOF  in  a  testbed  of  195  Stargates  [1]  with  802.1  lb 
radios.  For  instance,  we  investigate  the  validity  of  geographic 
uniformity  which  is  assumed  in  literature  [19],  and  we  find  that 
it  usually  does  not  hold  and  leads  to  inferior  performance.  We 
also  compare  the  performance  of  LOF  with  that  of  existing  pro¬ 
tocols,  represented  by  the  geography-unaware  ETX  [8,  21]  and 
the  geography -based  PRD  [19].  We  find  that  LOF,  apart  from 
guaranteeing  100%  packet  delivery,  reduces  end-to-end  MAC 
latency,  reduces  energy  consumption  in  packet  delivery,  and  im¬ 
proves  route  stability.  Besides  bursty  event  traffic,  we  evaluate 
LOF  in  the  case  of  periodic  traffic,  and  we  find  that  LOF  out¬ 
performs  existing  protocols  in  that  case  too.  As  a  side  result,  we 
compare  the  performance  of  ETX  with  that  of  PRD,  which  has 
not  been  done  in  the  literature. 

Organization  of  the  paper.  In  Section  2,  we  study  the  short¬ 
comings  of  beacon-based  routing,  and  we  analyze  the  feasibility 
of  beacon-free  routing.  Following  that,  we  present  the  routing 
metric  ELD  in  Section  3,  and  we  design  the  protocol  LOF  in 
Section  4.  We  experimentally  evaluate  LOF  in  Section  5,  and 
we  discuss  the  related  work  in  Section  6.  We  make  concluding 
remarks  in  Section  7. 

2  Why  beacon-free  routing 

Routing  protocols  that  estimate  link  properties  using  periodic 
beacons  implicitly  assume  the  following: 

I.  Link  properties  estimated  via  broadcast  beacons  apply  to 
unicast  data  packets; 

II.  Link  properties  experienced  by  periodic  beacons  reflect 
those  in  the  presence  of  data  traffic. 

These  assumptions  are  usually  invalid  in  wireless  networks,  even 
though  they  hold  well  in  wireline  networks  where  links  are  reli¬ 
able. 

In  this  section,  we  experimentally  investigate  the  invalidity  of 
these  assumptions  in  wireless  networks,  then  we  discuss  the  fea¬ 
sibility  of  beacon-free  routing. 

2.1  Experiment  design 

To  check  the  validity  of  assumptions  I  and  II  and  to  study  the 

impact  of  packet  type,  packet 
length,  and  interference  on  link 
properties,  we  set  up  two  802.11b 
network  testbeds  as  follows. 

Outdoor  testbed.  In  an  open 
field  (see  Figure  1),  we  deploy  29 
Stargates  in  a  straight  line,  with  a 


45-meter  separation  between  any 
two  consecutive  Stargates.  The 
Stargates  run  Linux  with  kernel  2.4.19.  Each  Stargate  is 
equipped  with  a  SMC  2.4GHz  802. 1  lb  wireless  card  and  a  9dBi 
high-gain  collinear  omnidirectional  antenna,  which  is  raised  1 .5 
meters  above  the  ground.  To  control  the  maximum  communica¬ 
tion  range,  the  transmission  power  level1  of  each  Stargate  is  set 
as  35. 

Indoor  testbed.  In  an  open  warehouse  (see  Figure  2(a)),  we 
deploy  195  Stargates  in  a  15  x  13  grid  (as  shown  in  Figure  2(b)) 
where  the  separation  between  neighboring  grid  points  is  0.91 
meter  (i.e.,  3  feet).  For  convenience,  we  number  the  rows  of 


(a)  testbed  (b)  grid  topology 

Figure  2:  Indoor  testbed 

the  grid  as  0  -  12  from  the  bottom  up,  and  the  columns  as  0  - 
14  from  the  left  to  the  right.  Each  Stargate  is  equipped  with  the 
same  SMC  wireless  card  as  in  the  outdoor  testbed.  To  create  re¬ 
alistic  multi-hop  wireless  networks,  each  Stargate  is  equipped  a 
2.2dBi  rubber  duck  omnidirectional  antenna  and  a  20dB  atten¬ 
uator.  We  raise  the  Stargates  1.01  meters  above  the  ground  by 
putting  them  on  wood  racks.  The  transmission  power  level  of 
each  Stargate  is  set  as  60. 

The  Stargates  in  the  indoor  testbed  are  equipped  with  wall- 
power  and  outband  Ethernet  connections,  which  facilitate  long- 
duration  complex  experiments  at  low  cost.  We  use  the  indoor 
testbed  for  most  of  the  experiments  in  this  paper;  we  use  the  out¬ 
door  testbed  mainly  for  checking,  in  Section  2.2.1,  the  generality 
of  the  phenomena  observed  in  the  indoor  testbed. 

Experiments.  In  the  outdoor  testbed,  the  Stargate  at  one  end 
acts  as  the  sender,  and  the  other  Stargates  act  as  receivers.  Given 
the  constraints  of  time  and  experiment  control,  we  leave  complex 
experiments  to  the  indoor  testbed  and  only  perform  relatively 
simple  experiments  in  the  outdoor  testbed:  the  sender  first  sends 
30,000  1200-byte  broadcast  packets,  then  it  sends  30,000  1200- 
byte  unicast  packets  to  each  of  the  receivers.  This  experiment  is 
designed  to  invalidate  assumption  I. 

In  the  indoor  testbed,  we  let  the  Stargate  at  column  0  of  row 
6  be  the  sender,  and  the  other  Stargates  in  row  6  act  as  receivers. 
To  study  the  impact  of  interference,  we  consider  the  following 
scenarios  (which  are  named  according  to  the  interference): 

•  Interferer-free :  there  is  no  interfering  transmission.  The 
sender  first  sends  30,000  broadcast  packets  each  of  1200 
bytes,  then  it  sends  30,000  1200-byte  unicast  packets  to 
each  of  the  receivers,  and  lastly  it  broadcasts  30,000  30- 
byte  packets. 

1 A  tunable  parameter  for  802. 1  lb  wireless  cards.  The  range  for  the  power  level  is  127, 
126, . . . ,  0,  255,  254, . . . ,  129,  128,  with  127  being  the  lowest  and  128  being  the  highest. 


Figure  1:  Outdoor  testbed 
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•  Interferer-close :  one  “interfering”  Stargate  at  column  0  of 
row  5  keeps  sending  1200-byte  unicast  packets  to  the  Star- 
gate  at  column  0  of  row  7,  serving  as  the  source  of  the  in¬ 
terfering  traffic.  The  sender  first  sends  30,000  1200-byte 
broadcast  packets,  then  it  sends  30,000  1200-byte  unicast 
packets  to  each  of  the  receivers. 

•  Interferer-middle :  the  Stargate  at  column  7  of  row  5  keeps 
sending  1200-byte  unicast  packets  to  the  Stargate  at  column 
7  of  row  7.  The  sender  performs  the  same  as  in  the  case  of 
interferer-close. 

•  Interferer-far.  the  Stargate  at  column  14  of  row  5  keeps 
sending  1200-byte  unicast  packets  to  the  Stargate  at  column 
14  of  row  7.  The  sender  performs  the  same  as  in  the  case  of 
interferer-close. 

•  Interferer-exscal:  In  generating  the  interfering  traffic,  ev¬ 
ery  Stargate  runs  the  routing  protocol  LOF  (as  detailed  in 
later  sections  of  this  paper),  and  the  Stargate  at  the  upper- 
right  corner  keeps  sending  packets  to  the  Stargate  at  the  left- 
bottom  corner,  according  to  an  event  traffic  trace  from  the 
field  sensor  network  of  ExScal  [5]  .  The  traffic  trace  cor¬ 
responds  to  the  packets  generated  when  a  vehicle  passes 
across  a  section  of  the  ExScal  network.  In  the  trace,  19 
packets  are  generated,  with  the  first  9  packets  correspond¬ 
ing  to  the  start  of  the  event  detection  and  the  last  10  packets 
corresponding  to  the  end  of  the  event  detection.  Figure  3 
shows,  in  sequence,  the  intervals  between  packets  1  and  2, 


Figure  3:  The  traffic  trace  of  an  ExScal  event 


2  and  3,  and  so  on.  The  sender  performs  the  same  as  in  the 
case  of  interferer-close. 

In  all  of  these  experiments,  except  for  the  case  of  interferer- 
exscal,  the  packet  generation  frequency,  for  both  the  sender  and 
the  interferer,  is  1  packet  every  20  milliseconds.  In  the  case  of 
interferer-exscal,  the  sender  still  generates  1  packet  every  20  mil¬ 
liseconds,  yet  the  interferer  generates  packets  according  to  the 
event  traffic  trace  from  ExScal,  with  the  inter-event-run  interval 
being  10  seconds.  The  above  experiments  are  designed  to  inval¬ 
idate  both  assumptions  I  and  II.  (Note  that  the  scenarios  above 
are  far  from  being  complete,  but  they  would  give  us  a  sense  of 
how  different  interfering  patterns  affect  link  properties.) 

In  the  experiments,  broadcast  packets  are  transmitted  at  the 
basic  rate  of  1M  bps  and,  without  loss  of  generality,  we  configure 
the  unicast  transmission  rate  to  be  11Mbps.  For  other  802.11b 
configurations,  we  use  the  default  parameter  values  that  come 
with  the  system  software.  For  instance,  each  unicast  packet  is 
retransmitted  up  to  7  times  until  success  or  failure  in  the  end. 


2.2  Experimental  results 

For  each  case,  we  measure  various  link  properties,  such  as  packet 
delivery  rate  and  the  run  length  of  packets  successfully  received 
without  any  loss  in  between,  for  each  link  defined  by  the  sender 
-  receiver.  Due  to  space  limitations,  however,  we  only  present 
the  data  on  packet  delivery  rate  here.  The  packet  delivery  rate  is 
calculated  once  every  100  packets. 

We  first  present  the  difference  between  broadcast  and  unicast 
when  there  is  no  interference,  then  we  present  the  impact  of  in¬ 
terference. 

2.2.1  Interferer  free 

Figure  4  shows  the  scatter  plot  of  the  delivery  rates  for  broadcast 


(a)  broadcast  (b)  unicast 

Figure  4:  Outdoor  testbed 

and  unicast  packets  at  different  distances  in  the  outdoor  testbed. 
From  the  figure,  we  observe  the  following: 

•  Broadcast  has  longer  communication  range  than  unicast. 
This  is  due  to  the  fact  that  the  transmission  rate  for  broad¬ 
cast  is  lower,  and  that  there  is  no  RTS-CTS  handshake  for 
broadcast. 

•  For  links  where  unicast  has  non-zero  delivery  rate,  the  mean 
delivery  rate  of  unicast  is  higher  than  that  of  broadcast.  This 
is  due  to  the  fact  that  each  unicast  packet  is  retransmitted  up 
to  7  times  upon  failure. 

•  The  variance  in  packet  delivery  rate  is  lower  in  unicast  than 
that  in  broadcast.  This  is  due  to  the  fact  that  unicast  pack¬ 
ets  are  retransmitted  upon  failure,  and  the  fact  that  there  is 
RTS-CTS  handshake  for  unicast. 

Similar  results  are  observed  in  the  indoor  testbed,  as  shown  in 
Figures  5(a)  and  5(b).  Nevertheless,  there  are  exceptions  at  dis¬ 
tances  3.64  meters  and  5.46  meters,  where  the  delivery  rate  of 
unicast  takes  a  wider  range  than  that  of  broadcast.  This  is  likely 
due  to  temporal  changes  in  the  environment.  Comparing  Fig¬ 
ures  5(a)  and  5(c),  we  see  that  packet  length  also  has  significant 
impact  on  the  mean  and  variance  of  packet  delivery  rate. 
Implication.  From  Figures  4  and  5,  we  see  that  packet  delivery 
rate  differs  significantly  between  broadcast  and  unicast,  and  the 
difference  varies  with  environment,  hardware,  and  packet  length. 
Therefore,  assumption  I  does  not  hold  well  even  when  there  is  no 
interference. 

2.2.2  Interfering  scenarios 

Figure  6  shows  how  the  difference  between  broadcast  and  uni- 
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(a)  broadcast:  1200-byte  packet 


(b)  unicast:  1200-byte  packet 


(a)  broadcast 


(b)  unicast 


(c)  broadcast:  30-byte  packet 


Figure  5:  Indoor  testbed 


Figure  7:  Relative  change  in  packet  delivery  rate 
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Figure  6:  The  difference  between  broadcast  and  unicast  in  dif¬ 
ferent  interfering  scenarios 


Figure  8:  Relative  change  in  the  COV  of  packet  delivery  rate 

Implication.  For  wireless  sensor  networks  where  data  bursts 
are  well  separated  in  time  and  possibly  in  space  (e.g.,  in  bursty 
convergecast),  the  link  properties  experienced  by  periodic  bea¬ 
cons  may  well  differ  from  those  experienced  by  data  traffic. 
Thus  assumption  II  does  not  hold  well.  Moreover,  the  difference 
between  broadcast  and  unicast  changes  as  interference  pattern 
changes. 


cast  in  the  mean  packet  delivery  rate  changes  as  the  interfer¬ 
ence  and  distance  change.  Given  a  distance  and  an  interfering 
scenario,  the  difference  is  calculated  as  U  ,  where  U  and  B 
denote  the  mean  delivery  rate  for  unicast  and  broadcast  respec¬ 
tively.  From  the  figure,  we  see  that  the  difference  is  signifi¬ 
cant  (up  to  94.06%),  and  that  the  difference  varies  with  distance. 
Moreover,  the  difference  changes  significantly  (up  to  103.41%) 
as  interference  pattern  changes.  This  observation  further  demon¬ 
strates  the  invalidity  of  assumption  I  in  wireless  networks. 

Figures  7  and  8  show  the  relative  changes,  when  compared 
with  the  case  of  interferer-free,  in  packet  delivery  rate  and  its 
coefficient  of  variation  (COV)2  under  different  interfering  sce¬ 
narios.  Given  a  distance  and  an  interfering  scenario,  the  rela¬ 
tive  change  is  calculated  as  where  I  and  F  denote  the  pa¬ 
rameter  value  in  the  presence  and  in  the  absence  of  the  interfer¬ 
ence  respectively;  if  I  or  F  is  0,  we  do  not  calculate  the  relative 
change  since  the  value  would  be  less  meaningful.  From  the  fig¬ 
ures,  we  see  that  both  the  mean  and  the  COV  of  packet  delivery 
rate  change  significantly  for  broadcast  when  there  is  interference, 
yet  the  relative  changes  for  unicast  are  much  less.  Moreover,  the 
relative  changes  vary  as  interfering  scenarios  and  distances  vary. 

2COV  is  defined  as  the  standard  deviation  divided  by  the  mean  [15]. 


2.3  Beacon-free  routing 

To  estimate  unicast  link  properties  in  spite  of  the  difference  be¬ 
tween  broadcast  and  unicast,  there  are  two  alternatives:  estimat¬ 
ing  unicast  link  properties  based  on  those  of  broadcast  beacons 
but  compensate  for  the  difference;  or  estimating  unicast  link 
properties  directly.  From  Section  2.2,  we  see  that  the  differ¬ 
ence  assumes  complex  patterns,  as  factors  such  as  environment, 
packet  length,  and  interference  pattern  change.  Therefore,  it  is 
not  trivial,  if  even  possible,  to  mathematically  model  the  differ¬ 
ence  and  to  compensate  for  it  in  estimation.  To  circumvent  this 
difficulty,  we  adopt  the  second  approach,  that  is,  directly  esti¬ 
mating  unicast  link  properties  without  using  beacons. 

Traditionally,  beacons  serve  two  major  roles:  diffusing  infor¬ 
mation  (e.g.,  the  expected  number  of  transmissions  to  the  base 
station)  and  acting  as  the  basis  for  link  quality  estimation.  To 
enable  beacon-free  routing,  there  must  be  mechanisms  perform¬ 
ing  these  two  tasks.  In  wireless  sensor  networks,  beacon-free 
routing  is  enabled  by  the  following  facts: 

•  Nodes  are  static  most  of  the  time,  and  their  geographic  loca¬ 
tions  are  readily  available  via  devices  such  as  GPS.  There¬ 
fore,  we  can  use  geography-based  routing  in  which  a  node 
only  needs  to  know  the  location  of  the  destination  and  the 
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information  regarding  its  local  neighborhood  (such  as  the 
quality  of  the  links  to  its  neighbors).  Thus,  only  the  location 
of  the  destination  (e.g.,  the  base  station  in  convergecast) 
needs  to  be  diffused  across  the  network.  Unlike  in  beacon- 
based  distance-vector  routing,  the  diffusion  happens  infre¬ 
quently  since  the  destination  is  static  most  of  the  time.  In 
general,  control  packets  are  needed  only  when  the  location 
of  a  node  changes,  which  occurs  infrequently. 

•  In  MACs  where  every  frame  transmission  is  acknowledged 
by  the  receiver  (e.g.,  in  the  802.11b  MAC),  the  sender 
can  determine  if  a  transmission  has  succeeded  by  check¬ 
ing  whether  it  receives  the  acknowledgment3.  Also,  the 
sender  can  determine  how  long  each  transmission  takes  (as 
to  be  explained  in  detail  in  Section  4.5),  i.e.,  MAC  latency. 
Therefore,  the  sender  is  able  to  get  information  on  link  qual¬ 
ity  without  using  any  beacons. 

In  what  follows,  we  first  present  the  routing  metric  ELD  which 
is  based  on  geography  and  MAC  latency,  then  we  present  the 
design  of  LOF  which  implements  ELD  in  a  beacon-free  manner. 

3  ELD:  the  routing  metric 

In  this  section,  we  first  justify  mathematically  why  MAC  la¬ 
tency  reflects  link  reliability  and  energy  consumption,  then  we 
derive  the  routing  metric  ELD,  the  expected  MAC  latency  per 
unit-distance  toward  the  destination ,  and  finally  we  analyze  the 
consequent  sample  size  requirement  in  routing. 

3.1  MAC  latency  as  the  basis  for  route  selection 

For  convergecast  in  sensor  networks  (especially  for  event-driven 
applications),  packets  need  to  be  routed  reliably  and  in  real-time 
to  the  base  station.  As  usual,  packets  should  also  be  delivered  in 
an  energy-efficient  manner.  Therefore,  a  routing  metric  should 
reflect  link  reliability,  packet  delivery  latency,  and  energy  con¬ 
sumption  at  the  same  time.  One  such  metric  that  we  adopt  in 
LOF  is  based  on  MAC  latency  (i.e.,  the  time  taken  for  the  MAC 
to  transmit  a  data  frame). 

Intuitively,  both  the  MAC  latency  and  the  energy  consumption 
of  a  frame  transmission  depend  on  the  link  reliability.  Therefore 
MAC  latency  certainly  reflects  link  reliability  and  energy  con¬ 
sumption.  But  to  precisely  characterize  their  relationships,  we 
mathematically  analyze  them  as  follows,  using  802.11b  as  an 
example.  (Readers  unfamiliar  with  the  details  of  802. lib  could 
refer  to  [4],  or  simply  skip  the  mathematical  formulation  and 
only  check  for  the  pictorial  representation.) 

Given  a  sender  S  and  a  receiver  R  where  the  link  between 
them  has  non-zero  reliability,  we  let  Dr.r  and  Ps,r  denote  the 
MAC  latency  and  the  energy  consumption  for  transmitting  a  uni¬ 
cast  frame  from  S  to  R.  Then,  we  are  interested  in  calculating 
the  expected  values  E(Ds,r)  and  E(Ps.r).  For  simplicity,  we 
only  consider  the  case  where  there  is  no  interfering  traffic,  and 
we  assume  that  the  MAC  continues  to  transmit  a  packet  until  it  is 
successful.  Let  po  be  the  probability  that  a  RTS-CTS  handshake 
between  S  and  R  will  fail  (e.g.,  due  to  the  loss  of  RTS  or  CTS) 

3  Even  though  this  method  is  not  perfect  when  an  acknowledgment  frame  can  get  lost,  it 
works  well  in  practice  given  the  low  probability  of  losing  an  acknowledgment  frame. 


(po  >  0),  pi  be  the  probability  that  a  DATA-ACK  handshake 
between  S  and  R  will  fail  (pi  >  0),  and  C  =  Po  +  Pi  ~  PoPi- 
Then,  we  have 

E(DS,R)  =  (l-p0)(l-pi)(464  +  fd)  +  (^ff)T  (ps)  (1) 
where 

td  —  time  taken  to  transmit  the  DATA  frame  (in  microseconds); 

T  =  (502  +  C^+^dXl-Poipi )  2^_~^  + 

15872QC*-138880C9  ,  (-«a~482)C2 

(1-C)2  9  C 

119040C8  1004p2-502p8  , 

1-0  (1  Po  )2  + 

—  1 58  720p8  + 1 38880p9  ,  (fd+482)p2  , 

(I--P0)2  +  1  P0  + 

+  155EI0=2((2C)*0  -  (2po)fc°). 

Derivation  sketch  for  formula  (1).  Assume  a  frame  transmission 
from  S  to  R  takes  k\  rounds  of  DATA-ACK  handshakes  and  ko 
rounds  of  RTS-CTS  handshakes.  Clearly,  kp  >  k\ .  Then,  the 
MAC  latency  Dg.Rfko,  ki)  can  be  decomposed  into  the  follow¬ 
ing  three  components: 

•  The  latency  I(ko,ki)  due  to  the  initial  DIFS  before  any 
RTS -CTS -DATA-ACK  handshake.  We  have  J(fc0,fci)  = 
DIFS  (1 us). 

•  The  latency  CB(ko,  ki)  due  to  the  contention  avoidance 
backoffs:  there  are  ( kp  —  ki)  RTS-CTS  handshake  failures, 
(fci  —  1)  DATA-ACK  handshake  failures,  and  ( ko  —  k±)  + 
(k\  —  1)  =  ko  —  1  contention  backoffs.  Therefore,  we  have 

C%,h)  =  (k0- k1)(CTSTimeout  + DIFS)+ 

(/ci  -  1)  (ACKTimeout  +  DIFS)+ 

where  CTSTimeout  =  trts  +  tcts  +  2  SIFS. 
ACKTimeout  =  td  +  tack  +  SIFS  +  DIFS,  and  BTi  is 
the  value  of  the  ith  contention  backoff  timer. 

•  The  latency  DT(kp.  k\)  due  to  the  normal  RTS-CTS- 
DATA-ACK  procedure.  We  have 

DT(ko,ki)  =  (ko  —  ki)trts  + 

k\(trts  T  SIFS  +  tcfs)T 
(SIFS  +  td  +  SIFS  +  tack)  (ps) 

where  trts.  tcts.  and  tack  denote  the  time  taken  to  transmit 
a  RTS,  a  CTS,  and  an  ACK  respectively. 

Therefore,  we  have 

dS,r(^oAi)  =  I(ko,k\)  +  CB(ko,k\)  A  DT(ko,k\) 

=  ko(DIFS  +  trts  +  CT  STimeout)+ 
k\(— CTSTimeout  +  AC  KTimeout+ 
tcts  +  3SIFS  +  td  +  tack)— 
ACKTimeout  +  E^gf  BTt 

Now,  let  us  calculate  the  probability  P(ko,  ki)  that  a  transmis¬ 
sion  from  S  to  R  takes  ko  rounds  of  RTS-CTS  handshake  and  k\ 
rounds  of  DATA-ACK  handshake.  We  have  P(ko,  ki)  = 

P{(k 0  —  ki)  RTS-CTS  failure  out  of  ko  times} x 
P{{ki  —  1)  DATA-ACK  failures  followed  by  a  success} 

(((k0-V>o°'fcl(l-Po)fcU  xbUi-Hl-Pi))  iiko>ki 
0  otherwise 

0  otherwise 
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Figure  9:  MAC  latency  as  an  indicator  of  energy  consumption 


Therefore,  we  have 

E{DS,R )  =  Ek0M  (.Ds,n(ko,ki)) 

=  iJJS  Efc°=i  DS,R{ko,ki)P{ko,ki) 


routing  metrics  optimizing  MAC  latency  would  also  optimize 
energy  efficiency.  Note  that,  as  link  reliability  becomes  too  low, 
the  rate  of  increase  in  MAC  latency  is  slightly  faster  compared 
to  energy  consumption.  This  is  because  the  contention  window 
for  the  random  backoff  in  MAC  increases  exponentially.  In  prac¬ 
tice,  however,  this  scenario  may  not  happen,  because  extremely 
low  link  reliability  only  leads  to  transmission  failures  due  to  the 
upper  limit  on  the  number  of  retries  (whose  default  value  is  7). 

Previous  work  has  argued  the  advantages  of  using  routing  met¬ 
rics  Expected  Transmission  Count  (ETX)  [21,  8]  and  Expected 
Transmission  Time  (ETT)  [10,  9],  which  are  similar  to  MAC 
latency,  from  perspectives  such  as  reducing  self-interference 
and  increasing  throughput.  Our  analysis  complements  theirs  by 
mathematically  showing  the  relationships  among  MAC  latency, 
energy  consumption,  and  link  reliability. 


Applying  802.11b  parameters,  such  as  trts  and  SIFS ,  to  the 
above  formula,  we  could  arrive  at  formula  (1).  Due  to  the  limi¬ 
tation  of  space,  we  skip  the  detail  here. 

□ 

For  energy  consumption,  we  have 


e{Ps,r) 

where 


pi(i~-c)^  (34C  +  &  +  14>i -  «>)(2  -  c))  (^es) 

(2) 


l, l  =  the  length  of  the  DATA  frame  (in  number  of  bytes). 


Derivation  sketch  for  formula  (2).  Let  k o,  fci,  and  P(fco,fci) 
be  the  same  as  in  the  “derivation  sketch  for  formula  (1).  Let 
Brts-cts  be  the  length,  in  number  of  bytes,  of  a  RTS-CTS  pair, 
and  Bdata-ack  be  the  length  of  a  DATA-ACK  pair.  Then,  if  a 
transmission  from  S  to  R  takes  hj  rounds  of  RTS-CTS  hand¬ 
shakes  and  fci  rounds  of  DATA-ACK  handshakes  (fco  >  fci),  the 
energy  Ps,R(ko,  fci)  consumed,  in  number  of  bytes  transmitted, 
is  fco^rts— cts  T  fci Bdata-ack- 

Therefore,  we  have 

E(PS,r)  =  -BJ!0,fc1(Cs,.R(fco,fcl)) 

=  Efc^=i  £fci=i  pS,R(ko,ki)P(k0,ki) 

Applying  802.11b  parameters,  such  as  Brts_cts,  to  the  above 
formula,  we  could  arrive  at  formula  (2).  Due  to  the  limitation  of 
space,  we  skip  the  detail  here. 

□ 

To  draw  Formulas  (1)  and  (2),  we  let  the  probability  p[  that 
a  DATA-ACK  handshake  will  succeed  represent  link  reliability 
(i.e.,  p[  =  1  -  pi).  Letting  fc  =  ’  and  assum¬ 

ing  that  bit  errors  are  independent,  we  have  pi  =  1  —  (1  —  po)k. 
Thus,  _ 

po  =  i  -  =  1  -  fa  0) 

Based  on  equations  (1),  (2),  (3),  and  assuming  that  td  is  1200, 
Figure  9  presents  a  visual  characterization  of  the  expected  MAC 
latency,  the  expected  energy  consumption,  and  the  ratio  between 
them,  as  link  reliability  changes. 

From  Figure  9,  we  see  that  MAC  latency  is  strongly  related  to 
energy  consumption  in  a  positive  manner,  and  the  ratio  between 
them  changes  only  slightly  as  link  reliability  changes.  Thus, 


3.2  ELD:  a  geography-based  routing  metric 


US,  R) 


Given  that  MAC  latency  is  a  good  basis  for  route  selection  and 
that  geography  enables  low  frequency  information  diffusion,  we 
define  a  routing  metric  ELD,  the  expected  MAC  latency  per 
unit-distance  toward  the  destination,  which  is  based  on  both 
MAC  latency  and  geography.  Specifically,  given  a  sender  S,  a 
neighbor  R  of  S,  and  the  destination  D  as  shown  in  Figure  10, 

we  first  calculate  the  effective  ge¬ 
ographic  progress  from  S  to  D 
via  R,  denoted  by  Le(S,R),  as 
( Ls,d  ~  where  Ls,d  de¬ 

notes  the  distance  between  S  and 
D,  and  LR:d  denotes  the  dis¬ 
tance  between  R  and  D.  Then, 
we  calculate,  for  the  sender 
S,  the  MAC  latency  per  unit- 
distance  toward  the  destination  (LD)  via  R,  denoted  by 
LD(S,  R),  as4 


D 


Figure  10:  Calculate  Le 


{ 


DS,R 

Le(S,R) 

oo 


if 

otherwise 


(4) 


where  D$,r  is  the  MAC  latency  from  S  to  R.  Therefore,  the 
ELD  via  R,  denoted  as  ELD(S,  R),  is  E(LD(S,  R))  which  cal¬ 
culates  as 


e(ds,rI 

Le(S,R ) 
OO 


if  eS,d  >  er,d 
otherwise 


(5) 


For  every  neighbor  R  of  S,  S  associates  with  R  a  rank 


{ELD(S,  R),  var(LD{S,  R)),  LR}D,ID(R)) 

where  var(LD(S,  R))  denotes  the  variance  of  LD(S,R),  and 
ID(R)  denotes  the  unique  ID  of  node  R.  Then,  S  selects  as  its 
next-hop  forwarder  the  neighbor  that  ranks  the  lowest  among  all 
the  neighbors.  Because  MAC  latency  and  LD  are  lognormally 
distributed  (to  be  discussed  in  Section  3.3),  the  ranks  are  com¬ 
pared  via  their  logarithmic  values  in  protocol  LOF. 

To  understand  what  ELD  implies  in  practice,  we  set  up  an  ex¬ 
periment  as  follows:  consider  a  line  network  formed  by  row  6  of 
the  indoor  testbed  shown  in  Figure  2,  the  Stargate  S  at  column 

4Currently,  we  focus  on  the  case  where  a  node  forwards  packets  only  to  a  neighbor  closer 
to  the  destination  than  itself. 
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0  needs  to  send  packets  to  the  Stargate  D  at  the  other  end  (i.e., 
column  14).  Using  the  data  on  unicast  MAC  latencies  in  the  case 
of  interferer-free ,  we  show  in  Figure  1 1  the  mean  unicast  MAC 


1-0- mean  MAC  latency  (ms)| 

J-y-ELD  (ms/meter) 


°0  2  4  6  8  10  12  14 

distance  (meter) 


Figure  1 1 :  Mean  unicast  MAC  latency  and  the  ELD 

latencies  and  the  corresponding  ELD’s  regarding  neighbors  at 
different  distances.  From  the  figure,  Stargate  D ,  the  destination 
which  is  12.8  meters  away  from  S ,  offers  the  lowest  ELD,  and 
S  sends  packets  directly  to  D .  From  this  example,  we  see  that, 
using  metric  ELD,  a  node  tends  to  choose  nodes  beyond  the  re¬ 
liable  communication  range  as  forwarders,  to  reduce  end-to-end 
MAC  latency  as  well  as  energy  consumption. 

Remark.  ELD  is  a  locally  measurable  metric  based  only  on 
the  geographic  locations  of  nodes  and  information  regarding  the 
links  associated  with  the  sender  S;  ELD  does  not  assume  link 
conditions  beyond  the  local  neighborhood  of  S.  In  the  literature 
of  geographic  routing  [19],  however,  a  common  assumption  is 
that  the  hops  in  any  route  have  similar  properties  such  as  geo¬ 
graphic  length  and  link  quality.  As  we  will  show  by  experiments 
in  Section  5,  this  assumption  is  usually  invalid.  For  the  sake 
of  verification  and  comparison,  we  derive  another  routing  met¬ 
ric  ELR,  the  expected  MAC  latency  along  a  route,  based  on  this 
assumption.  More  specifically,  ELR(S ,  R)  = 

e(dS,r)  X  [ Lb'l^LRB'D  1  if  LS,D  >  LR’D  ^ 

oo  otherwise 

where  [  Ls,^^R,p  ]  denotes  the  number  of  hops  to  the  destina¬ 
tion,  assuming  equal  geographic  distance  at  every  hop.  We  will 
show  in  Section  5  that  ELR  is  inferior  to  ELD. 

3.3  Sample  size  requirement 

To  understand  the  convergence  speed  of  ELD-based  routing  and 
to  guide  protocol  design,  we  experimentally  study  the  sample 
size  required  to  distinguish  out  the  best  neighbor  in  routing. 

In  our  indoor  testbed,  let  the  Stargate  at  column  0  of  row  6 
be  the  sender  S  and  Stargate  at  the  other  end  of  row  6  be  the 
destination  D\  then  let  S  send  30,000  1200-byte  unicast  packets 
to  each  of  the  other  Stargates  in  the  testbed,  to  get  information 
(e.g.,  MAC  latency  and  reliability)  on  all  the  links  associated 
with  S.  The  objective  is  to  see  what  sample  size  is  required  for 
S  to  distinguish  out  the  best  neighbor. 

First,  we  need  to  derive  the  distribution  model  for  MAC  la¬ 
tency.  Figure  12  shows  the  histogram  of  the  unicast  MAC  laten¬ 
cies  for  the  link  to  a  node  3.65  meters  (i.e.,  12  feet)  away  from 
S.  (The  MAC  latencies  for  other  links  assume  similar  patterns.) 
Given  the  shape  of  the  histogram  and  the  fact  that  MAC  latency 


Figure  12:  Histogram  for  unicast  MAC  latency 

is  a  type  of  “service  time”,  we  select  three  models  for  evalua¬ 
tion:  exponential,  gamma,  and  lognormal.5  Against  the  data  on 
the  MAC  latencies  for  all  the  links  associated  with  S,  we  perform 
Kolmogorov-Smirnov  test  [14]  on  the  three  models,  and  we  find 
that  lognormal  distribution  fits  the  data  the  best. 

Therefore,  we  adopt  lognormal  distribution  for  the  analysis  in 
this  paper.  Given  that  MAC  latency  assumes  lognormal  distribu¬ 
tion,  the  LD  associated  with  a  neighbor  also  assumes  lognormal 
distribution,  i.e.,  log(LD)  assumes  normal  distribution. 

Because  link  quality  varies  temporally,  the  best  neighbor  for 
S  may  change  temporally.  Therefore,  we  divide  the  30,000 
MAC  latency  samples  of  each  link  into  chunks  of  length  Lc,  de¬ 
noted  as  the  granularity  of  comparison,  and  we  compare  all  the 
links  via  their  corresponding  sample-chunks.  Given  each  sample 
chunk  for  the  MAC  latency  of  a  link,  we  compute  the  sample 
mean  and  sample  variance  for  the  corresponding  log(LD),  and 
use  them  as  the  mean  and  variance  of  the  lognormal  distribu¬ 
tion.  When  considering  the  i- th  sample  chunks  of  all  the  links 
(i  =  1,  2, ...,  |~ 3oooo  j),  we  gncj  tjle  best  ijnjf  according  to  these 
sample  chunks,  and  we  compute  the  sample  size  required  for 
comparing  this  best  link  with  each  of  the  other  links  as  follows: 
Given  two  normal  variates  AG,  AG  where  X\  ~ 
N(pi,S±)  and  AG  ~  N(p 2,^2)’  the  sample  size  re¬ 
quired  to  compare  AG  and  AG  at  100(1  —  a)%  con¬ 
fidence  level  is  ( )2  (0  <  a  <  1),  with  Za 
being  the  a-quantile  of  a  unit  normal  variate  [15]. 

In  the  end,  we  have  a  set  of  sample  sizes  for  each  specific  Lc. 
For  a  95%  confidence  level  comparison  and  route  selection,  Fig¬ 
ure  13(a)  shows  the  75-,  80-,  85-,  90-,  and  95-percentiles  of  the 
sample  sizes  for  different  Lf  s.  We  see  that  the  percentiles  do 
not  change  much  as  Lc  changes.  Moreover,  we  observe  that, 
even  though  the  90-  and  95-percentiles  tend  to  be  large,  the  75- 
and  80-percentiles  are  pretty  small  (e.g.,  being  3  and  8  respec¬ 
tively  when  Lc  is  20),  which  implies  that  routing  decisions  can 
converge  quickly  in  most  cases.  This  observation  also  motivates 
us  to  use  initial  sampling  in  LOF,  as  detailed  in  Section  4.2. 
Remark.  By  way  of  contrast,  we  may  also  compute  the  sample 
size  required  to  estimate  the  absolute  ELD  value  associated  with 
each  neighbor.  Figure  13(b)  shows  the  percentiles  for  a  95%  con¬ 
fidence  level  estimation  with  an  accuracy  of  ±5%.  We  see  that, 
even  though  the  90-  and  95-percentiles  are  less  than  those  for 
route  selection,  the  75-  and  80-percentiles  (e.g.,  being  47  and  56 
respectively  when  Lc  is  20)  are  significantly  greater  than  those 
for  route  selection.  Therefore,  when  analyzing  sample  size  re- 

5  The  methodology  of  LOF  is  independent  of  the  distribution  model  adopted.  Therefore, 
LOF  would  still  apply  even  if  better  models  are  found  later. 
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granularity  of  comparison  granularity  of  comparison 


(a)  route  selection  (b)  absolute  ELD 

Figure  13:  Sample  size  requirement 

quirement  for  routing,  we  should  focus  on  relative  comparison 
among  neighbors  rather  than  on  estimating  the  absolute  value, 
unlike  what  has  been  done  in  the  literature  [21]. 

4  LOF :  the  beacon-free  protocol 

Having  determined  the  routing  metric  ELD,  we  are  ready  to  de¬ 
sign  the  protocol  LOF  for  implementing  ELD  in  a  beacon-free 
manner.  Without  loss  of  generality,  we  only  consider  a  single 
destination,  i.e.,  the  base  station  to  which  every  other  node  needs 
to  find  a  route. 

Briefly  speaking,  LOF  needs  to  accomplish  two  tasks:  First, 
enabling  a  node  to  obtain  the  geographic  location  of  the  base  sta¬ 
tion,  as  well  as  the  IDs  and  locations  of  its  neighbors;  Second, 
enabling  a  node  to  track  the  LD  (i.e.,  MAC  latency  per  unit- 
distance  toward  the  destination)  regarding  each  of  its  neighbors. 
The  first  task  is  relatively  simple  and  only  requires  exchanging 
a  few  control  packets  among  neighbors  in  rare  cases  (e.g.,  when 
a  node  boots  up);  LOF  accomplishes  the  second  task  using  three 
mechanisms:  initial  sampling  of  MAC  latency,  adapting  estima¬ 
tion  via  MAC  feedback  for  application  traffic,  and  probabilisti¬ 
cally  switching  next-hop  forwarder. 

In  this  section,  we  first  elaborate  on  the  individual  components 
of  LOF,  then  we  discuss  implementation  issues  of  LOF  such  as 
reliably  fetching  MAC  feedback. 

4.1  Learning  where  we  are 

LOF  enables  a  node  to  learn  its  neighborhood  and  the  location 
of  the  base  station  via  the  following  rules: 

I.  [Issue  request]  Upon  boot-up,  a  node  broadcasts  M 
copies  of  hello-request  packets  if  it  is  not  the  base  station. 
A  hello-request  packet  contains  the  ID  and  the  geographic 
location  of  the  issuing  node.  To  guarantee  that  a  request¬ 
ing  node  is  heard  by  its  neighbors,  we  set  M  as  7  in  our 
experiments. 

II.  [Answer  request]  When  receiving  a  hello-request  packet 
from  another  node  that  is  farther  away  from  the  base  sta¬ 
tion,  the  base  station  or  a  node  that  has  a  path  to  the  base 
station  acknowledges  the  requesting  node  by  broadcasting 
M  copies  of  hello-reply  packets.  A  hello-reply  packet  con¬ 
tains  the  location  of  the  base  station  as  well  as  the  ID  and 
the  location  of  the  issuing  node. 


III.  [Handle  announcement]  When  a  node  A  hears  for  the 
first  time  a  hello-reply  packet  from  another  node  B  closer 
to  the  base  station,  A  records  the  ID  and  location  of  B  and 
regards  B  as  a  forwarder-candidate. 

IV.  [Announce  presence]  When  a  node  other  than  the  base 
station  finds  a  forwarder-candidate  for  the  first  time,  or 
when  the  base  station  boots  up,  it  broadcasts  M  copies  of 
hello-reply  packets. 

To  reduce  potential  contention,  every  broadcast  transmission 
mentioned  above  is  preceded  by  a  randomized  waiting  period. 
Note  that  the  above  rules  can  be  optimized  in  various  ways.  For 
instance,  rule  II  can  be  optimized  such  that  a  node  acknowledges 
at  most  one  hello-request  from  another  node  each  time  the  re¬ 
questing  node  boots  up.  Even  though  we  have  implemented  quite 
a  few  such  optimizations,  we  skip  the  details  here  since  they  are 
not  the  focus  of  this  paper. 

4.2  Initial  sampling 

Having  learned  the  location  of  the  base  station  as  well  as  the  lo¬ 
cations  and  IDs  of  its  neighbors,  a  node  needs  to  estimate  the 
LDs  regarding  its  neighbors.  To  design  the  estimation  mecha¬ 
nism,  let  us  first  check  Figure  14,  which  shows  the  mean  unicast 


Figure  14:  MAC  latency  in  the  presence  of  interference 

MAC  latency  in  different  interfering  scenarios  for  the  indoor  ex¬ 
periments  described  in  Section  2.1.  We  see  that,  even  though 
MAC  latencies  change  as  interference  pattern  changes,  the  rel¬ 
ative  ranking  in  the  mean  MAC  latency  among  links  does  not 
change  much.  Neither  will  the  LDs  accordingly. 

In  LOF,  therefore,  when  a  node  S  learns  of  the  existence  of  a 
neighbor  R  for  the  first  time,  S  samples  the  MAC  latency  of  the 
link  to  R  before  forwarding  any  data  packets  to  R.  The  sampling 
is  achieved  by  S  sending  unicast  packets  to  R  and  then  fetching 
the  MAC  feedback.  The  initial  sampling  gives  a  node  a  rough 
idea  of  the  relative  quality  of  the  links  to  its  neighbors,  to  jump 
start  the  data-driven  estimation. 

According  to  the  analysis  in  Section  3.3,  another  reason  for 
initial  sampling  is  that,  with  relatively  small  sample  size,  a  node 
could  gain  a  decent  sense  of  the  relative  goodness  of  its  neigh¬ 
bors.  We  set  the  initial  sample  size  as  8  (i.e.,  the  80-percentile  of 
the  sample  size  when  Lc  is  20)  in  our  experiments. 

4.3  Data-driven  adaptation 

Via  initial  sampling,  a  node  gets  a  rough  estimation  of  the  rela¬ 
tive  goodness  of  its  neighbors.  To  improve  its  route  selection  for 
an  application  traffic  pattern,  the  node  needs  to  adapt  its  estima¬ 
tion  of  LD  via  the  MAC  feedback  for  unicast  data  transmission. 
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Since  LD  is  lognormally  distributed,  LD  is  estimated  by  estimat¬ 
ing  log(LD). 

On-line  estimation.  To  determine  the  estimation  method,  we 
first  check  the  properties  of  the  time  series  of  log(LD),  consid¬ 
ering  the  same  scenario  as  discussed  in  Section  3.3.  Figure  15 
shows  a  time  series  of  the  log(LD)  regarding  a  node  3.65  me- 


Figure  15:  A  time  series  of  log(LD) 

ters  (i.e.,  12  feet)  away  from  the  sender  S  (The  log(LD)  for 
the  other  nodes  assumes  similar  patterns.).  We  see  that  the  time 
series  fits  well  with  the  constant-level  model  [13]  where  the  gen¬ 
erating  process  is  represented  by  a  constant  superimposed  with 
random  fluctuations.  Therefore,  a  good  estimation  method  is  ex¬ 
ponentially  weighted  moving  average  (EWMA)  [13],  assuming 
the  following  form 

V  < —  aV  +  (1  -  a)V'  (7) 

where  V  is  the  parameter  to  be  estimated,  V'  is  the  latest  obser¬ 
vation  of  V,  and  a  is  the  weight  (0  <  a  <  1). 

In  LOF,  when  a  new  MAC  latency  and  thus  a  new  log(LD) 
value  with  respect  to  the  current  next-hop  forwarder  R  is  ob¬ 
served,  the  V  value  in  the  right  hand  side  of  formula  (7)  may  be 
quite  old  if  R  has  just  been  selected  as  the  next-hop  and  some 
packets  have  been  transmitted  to  other  neighbors  immediately 
before.  To  deal  with  this  issue,  we  define  the  age  factor  j3{R) 
of  the  current  next-hop  forwarder  R  as  the  number  of  packets 
that  have  been  transmitted  since  V  of  R  was  last  updated.  Then, 
formula  (7)  is  adapted  to  be  the  following: 

V  * —  a0iR)V  +  (1  -  ap{R))V'  (8) 

(Through  experiments,  we  observe  that  formula  (8)  endows  LOF 
better  performance  than  formula  (7).) 

Each  MAC  feedback  indicates  whether  a  unicast  transmission 
has  succeeded  and  how  long  the  MAC  latency  l  is.  When  a  node 
receives  a  MAC  feedback,  it  first  calculates  the  age  factor  B(  R) 
for  the  current  next-hop  forwarder,  then  it  adapts  the  estimation 
of  log(LD)  as  follows: 

•  If  the  transmission  has  succeeded,  the  node  calculates  the 
new  log(LD)  value  using  l  and  applies  it  to  formula  (8) 
to  get  a  new  estimation  regarding  the  current  next-hop  for¬ 
warder. 

•  If  the  transmission  has  failed,  the  node  should  not  use  l  di¬ 
rectly  because  it  does  not  represent  the  latency  to  success¬ 
fully  transmit  a  packet.  To  address  this  issue,  the  node  keeps 
track  of  the  unicast  delivery  rate,  which  is  also  estimated  us¬ 
ing  formula  (8),  for  each  associated  link.  Then,  if  the  node 
retransmits  this  unicast  packet  via  the  currently  used  link. 


the  expected  number  of  retries  until  success  is  assuming 
that  unicast  failures  are  independent  and  that  the  unicast  de¬ 
livery  rate  along  the  link  is  p.  Including  the  latency  for  this 
last  failed  transmission,  the  expected  overall  latency  l1  is 
(1  +  i)Z.  Therefore,  the  node  calculates  the  new  log(LD) 
value  using  V  and  applies  it  to  formula  (8)  to  get  a  new  es¬ 
timation. 

Another  key  issue  in  the  EWMA  estimation  is  choosing  the 
right  weight  a,  since  it  affects  the  stability  and  agility  of  estima¬ 
tion.  To  address  this  question,  we  again  perform  experiment- 
based  analysis.  Using  the  data  from  Section  3.3,  we  try  out 
different  a  values  and  compute  the  corresponding  estimation  fi¬ 
delity,  that  is,  the  probability  of  LOF  choosing  the  right  next-hop 
forwarder  for  S.  Figure  16(a)  shows  the  best  a  value  and  the  cor¬ 
responding  estimation  fidelity  for  different  granularities  of  com¬ 
parison.  If  the  granularity  of  comparison  is  20,  for  instance, 
the  best  a  is  0.88,  and  the  corresponding  estimation  fidelity  is 
89.56%.  (Since  the  ExScal  traffic  trace  contains  19  packets,  we 
set  a  as  0.88  in  our  experiments.) 


(a)  best  a  (b)  sensitivity  analysis 

Figure  16:  The  weight  a  in  EWMA 

For  sensitivity  analysis.  Figure  16(b)  shows  how  the  estima¬ 
tion  fidelity  changes  with  a  when  the  granularity  of  comparison 
is  20.  We  see  that  the  estimation  fidelity  is  not  very  sensitive 
to  changes  in  a  over  a  wide  range.  For  example,  the  estimation 
fidelity  remains  above  85%  when  a  changes  from  0.6  to  0.98. 
Similar  patterns  are  observed  for  the  other  granularities  of  com¬ 
parison  too.  The  insensitivity  of  estimation  fidelity  to  a  guaran¬ 
tees  the  robustness  of  the  estimation  method.  Hence  we  may  not 
need  to  change  a  when  network  environment  changes. 

Route  adaptation.  As  the  estimation  of  LD  changes,  a  node  S 
adapts  its  route  selection  by  the  ELD  metric.  Moreover,  if  the 
unicast  reliability  to  a  neighbor  R  is  below  certain  threshold  (say 
60%),  S  will  mark  R  as  dead  and  will  remove  R  from  the  set  of 
forwarder-candidates.  If  S  loses  all  its  forwarder-candidates,  S 
will  first  broadcast  M  copies  of  hello-withdrawal  packets  and 
then  restarts  the  routing  process.  If  a  node  S'  hears  a  hello- 
withdrawal  packet  from  S,  and  if  S'  is  a  forwarder-candidate  of 
S',  S'  removes  S  from  its  set  of  forwarder-candidates  and  up¬ 
date  its  next-hop  forwarder  as  need  be.  (As  a  side  note,  we  find 
that,  on  average,  only  0.9863  neighbors  of  any  node  are  marked 
as  dead  in  both  our  testbed  experiments  and  the  field  deploy¬ 
ment  of  LOF  in  project  ExScal  [5].  Again,  the  withdrawing  and 
rejoining  process  can  be  optimized,  but  we  skip  the  details  here.) 
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4.4  Probabilistic  neighbor  switching 

Given  that  the  initial  sampling  is  not  perfect  (e.g.,  covering  80% 
instead  of  100%  of  all  the  possible  cases)  and  that  wireless  link 
quality  varies  temporally,  the  data-driven  adaptation  alone  may 
miss  using  good  links,  simply  because  they  were  relatively  bad 
when  tested  earlier  and  they  do  not  get  chance  to  be  tried  out 
later  on.  Therefore,  we  propose  probabilistic  neighbor  switching 
in  LOF.  That  is,  whenever  a  node  S  has  consecutively  transmit¬ 
ted  Ins(R0)  number  of  data  packets  using  a  neighbor  Rq ,  S  will 
switch  its  next-hop  forwarder  from  Ro  to  another  neighbor  R' 
with  probability  Pns(R').  On  the  other  hand,  the  probabilistic 
neighbor  switching  is  exploratory  and  optimistic  in  nature,  there¬ 
fore  it  should  be  used  only  for  good  neighbors.  In  LOF,  neighbor 
switching  only  considers  the  set  of  neighbors  that  are  not  marked 
as  dead. 

In  what  follows,  we  explain  how  to  determine  the  switching 
probability  Pns(R')  and  the  switching  interval  Ins(Rf).  For 
convenience,  we  consider  a  sender  S,  and  let  the  neighbors  of 
S  be  Ro,  Ri, . . . ,  Rn  with  increasing  ranks. 

Switching  probability.  At  the  moment  of  neighbor  switching, 
a  better  neighbor  should  be  chosen  with  higher  probability.  In 
LOF,  a  neighbor  is  chosen  with  the  probability  of  the  neighbor 
actually  being  the  best  next-hop  forwarder.  We  derive  this  proba¬ 
bility  in  three  steps:  the  probability  Pb(Ri,  Rj )  of  a  neighbor  P, 
being  actually  better  than  another  one  Rj  (given  by  formula  (9)), 
the  probability  Ph(Ri)  of  a  neighbor  Rt  being  actually  better 
than  all  the  neighbors  that  ranks  lower  than  itself  (given  by  for¬ 
mula  (10)),  and  the  probability  Pns(Ri)  of  a  neighbor  R,  being 
actually  the  best  forwarder  (given  by  formula  (11)). 

Given  S  and  its  two  neighbors  R,  and  Rj ,  we  approxi¬ 
mate  Pb(Ri,Rj)  with  P{LD(S,Ri)  >  LD(S,  Rj)},  which 
equals  P{log(LD(S,  Ri))  >  log(LD(S,  Rj))}.  As  discussed 
in  Section  3.3,  log(LD(S,  Ri))  as  well  as  log(LD(S,Rj))  has 
a  normal  distribution.  Assume  log{LD{S,  Rff)  NM), 
log(LD(S ,  Rj))  ~  N(fj,j,dj),  and  that  log(LD(S ,  Ri))  is  inde¬ 
pendent  of  log(LD(S,  Rj)),  then  we  have 

Pb(Ri,Rj)  =  G(^L)  (9) 

where  G(x )  =  1  —  with 


By  Andrew’s  method  [20],  P[Z  >  =  G(  ^ ,2  ^ ), 

V5;  +i53  v  1 +l5j 

where  G(x )  =  1  —  with 

f  erfc(— a/-\/(2))  a  <  0 

1  —  |erfc(a/-\/(2))  x  >  0 
erfc(x)  Ri  (T-A75)exp(-x2  +  P(j^)) 

P(x)  =  0.17087277a:9  -  0.82215223a;8  +  1.48851587a7- 
1.13520398a;6  +  0.27886807a;5  -  0.18628806a4+ 
0.09678418a;3  +  0.37409196a;2  +  1.00002368a- 
1.26551223 

□ 

Knowing  Pb(Rj,  Rk)  for  every  j  and  k,  we  compute  Pb(Ri) 
(i  =  1, ,  N)  inductively  as  follows: 

Pf t(#i)  =  pb(R  t,Ro)i 

Ph(Ri)  «  Pb{Ri,Ro)  x  n}  =  i(l  -  (Pb(Rj,Ri)  +  /in', 

(Ph(Rj)-l)xPb(R0,Ri)))  y  > 
(i=2,...,N) 


Derivation  sketch  for  formula  (10  ).  Let 

Pb  ((Rko:  Rm0  ),...,(Rkl,  Rm, ) )  denote  the  probability 
that  Rk0  is  better  than  Rmo ,  . . . ,  and  Rk,  is  better  than  Rm, , 
and  let  Pb((Ri,  Rj)\(Rko,  Rmo),  ■  ■  ■ ,  {Rk,,  Rm,))  denote  the 
probability  Ri  being  better  than  Rj  given  that  Rk0  is  better 
than  Rmo,  ...,  and  Rk,  is  better  than  Rrn, .  Then,  P/,  ( Rt ) 
f  i  — '  1 .... .  N)  is  computed  inductively  as  follows: 

Ph(R i)  =  pb{Ri,  Ro)', 

ph(Ri )  =  Pb(Ri,Ro)  x  Pb{(Rt j  Ri)\(Ri,  Ro))  x  . . . 

Pb{(Ri ,  Rj )  I  (Ri ,  Ro) ,  •  •  •  ,  (Ri ,  Rj-1 ))  x  ... 
pb((Ri,Ri-i)\(Ri,  Ro),  ■  ■  ■ ,  (Ri,Ri-2)) 

=  Pb(Ri,Ro)  X  npl  Pb((Ri ,  Rj)\(Ri ,  Ro) ,  ■  ■  ■  ,  (Ri,Rj- 1)) 

=  Pb(Ri,Ro)  X  nj=i(l  -  Pb((Rj,Ri)\(Ri,Ro),  ■■■,  (Ri,Rj- 1))) 
=  pb(Ri,  Ro)  x  nj=i(l  _  pb((Rj,Ri),  (Rj,Ro),--  ■ ,  (Rj,Rj~ i))) 
=  Pb(Ri,  Ro)  x  n;=i(l  —  (Pb(Rj ,  all  of  Ro  to  Rj-i)x 
Pi,  (any  of  Ro  to  Rj-i,  Ri)+ 

Pb(Rj,Ri)  X  Pb(Ri, allot  R0  to  Rj-i))) 

=  Pb(Ri,Ro)  X  n;=l(l  —  (Ph(Rj)  x  Pb( any  of  Ro  to  Rj-i ,  Ri)+ 
Pb(Rj,Ri)  x  Pb (Ri ,  all  of  Ro  to  Rj  —  i ))) 

=  Pb(Ri,Ro)  x  n}=l(l  -  (Pb(Rj,Ri)+ 

(Ph(Rj)  ~  l)Pb(any  of  Roto  Rj-i,  Rf))) 

Ri  Pb(Ri,  Ro)  x  nj=l(l  -  (Pb(Rj,Ri)  + 

(Ph(Rj)  -  1)  x  Pb(Ro,Ri))) 

(i  =  2, . . .  ,  N) 


<f>(x)  =  I  2erfc(-a:/V T2))  x  <  0 

[  1  -  |erfc(a;/Y/(2))  x  >  0 

erfc(a;)  Ri  (1+^2)  exp  (-a;2  +  P(j^)) 

P(x)  =  0.17087277a;9  -  0.82215223a®  +  1.48851587a7- 
1.13520398a6  +  0.27886807a5  -  0. 18628806a4 + 
0.09678418a3  +  0.37409196a2  +  1.00002368a- 
1.26551223. 


Then,  we  compute  the  switching  probability  as  follows: 

Pns(Ro)  =  Pb(Ro,Rt)  x  nf=2(l  -  Ph(Rj))', 

Pns(Ri)  =  Ph(Ri)  X  nf=,:+i(l  -  Ph(Rj)) 

(i  =  1, . . . ,  N  —  1); 


Pus(Rn)  —  Ph(Rn) 


□ 


(11) 


Derivation  sketch  for  formula  (9  ).  Since  log(LD(S,  Ri))  ~ 
N(jjh,%),  log(LD(S,Rj))  -  N{^,52j),  and  log(LD(S,  Rf) 
is  independent  of  log(LD(S,  Rj)),  it  is  easy  to  show  that  Z'  = 
log(LD(S,  Rf)) —log(LD(S,  Rj)  is  a  normal  variate  with  mean 

(Hi  —  fXj)  and  variance  (6f  +  S2).  Therefore,  Z  =  z  — ’ - 
is  a  standard  normal  variate.  Thus, 


Pb(Ri ,  Rj ) 


P{log(LD(S,Ri))  >  log(LD(S,Rj))} 
P[Z'  >0] 


Derivation  sketch  for  formula  (11  ).  Inductively, 

Pns(Ro)  =  Pb(Ro,Ri)  x  Pb((Ro,  R2)\(Ro,Ri))  x  . . . 

Pb((Ro,  Rn)\(Ro,Ri),  ■  ■  ■ ,  (Ro,Rn-i)) 

=  Pb(Ro,  Rt)  x  nf=2  pb((Ro,  Rj)\(Ro,Ri),  ■  ■  ■ ,  (Ro,  Rj- 1)) 

=  Pb(Ro,  Rt)  x  njL2(l  -  Pb((Rj,Ro)\(Ro,Ri),---,(Ro,Rj-i))) 
=  Pb(Ro,Rt)  x  nf=2(l  -  Ph(Rj))', 

Pns  (Ri)  —  Pfi(Ri)  X  Pb((Ri,  Rj)\(Ri,  Ro) ,  ■  ■  •  5  (Ri,  Rj—  l)) 

=  Ph(Ri)xn?=i+1G-Ph(Rj)) 

(i  =  l,...,N -If 

Pns  (Rn )  =  Ph(RN) 
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□ 

Because  of  the  approximation  in  formula  (10),  Pns(Ri) 
may  not  equal  to  1.  To  address  this  issue,  we  normalize  the 
P„s(i?j)’s  (i  =  0, ,  N)  such  that  their  sum  is  1. 

Switching  interval.  The  frequency  of  neighbor  switching 
should  depend  on  how  good  the  current  next-hop  forwarder  Ro 
is,  i.e.,  the  switching  probability  Pns(Rij).  In  LOF,  we  set  the 
switching  interval  Ins(Ro)  to  be  proportional  to  Pns(Ro ),  that 
is, 

/«,(/?o)  =  C  x  Pns{R0)  (12) 

where  C  is  a  constant  being  equal  to  (N  x  K),  with  N  being  the 
number  of  active  neighbors  that  S  has,  and  K  being  a  constant 
reflecting  the  degree  of  temporal  variations  in  link  quality.  We 
set  K  to  be  20  in  our  experiments. 

The  switching  probabilities  and  the  switching  interval  are  re¬ 
calculated  each  time  the  next-hop  forwarder  is  changed. 

4.5  Implementation  issues 

In  this  subsection,  we  discuss  implementation  issues  of  LOF. 
MAC  feedback  exfiltration.  In  LOF,  both  the  status  and  the 
MAC  latency  for  every  unicast  transmission  are  required.  Yet 
the  default  Linux  WLAN  driver  hostap  [3]  only  signals  for  failed 
unicast  transmissions,  and  it  does  not  signal  the  unicast  MAC  la¬ 
tency.  Therefore,  we  modify  the  Linux  kernel  and  the  hostap 
driver  such  that  the  transmission  status,  whether  success  or  fail¬ 
ure,  is  always  signaled  and  that  the  MAC  latency  is  reported  too. 
Since  we  implement  LOF,  using  EmStar  [2],  as  a  user-space  pro¬ 
cess,  MAC  feedback  is  sent  to  the  LOF  process  via  netlink  sock¬ 
ets  and  /proc  file  system  [12], 

Given  that  the  LOF  process  executes  in  user-space  and  that 
packet  transmission  is  supported  via  UDP  sockets  in  EmStar, 
there  is  memory  copying  in  the  procedure  between  the  LOF  pro¬ 
cess  sending  a  packet  and  the  hostap  driver  transmitting  the  cor¬ 
responding  802.11b  MAC  frame(s).  Thus,  one  issue  is  how  to 
map  a  data  transmission  at  the  user-space  with  the  frame  trans¬ 
mission  at  the  driver  and  thus  the  MAC  feedback.  Fortunately, 
the  data  buffers  in  EmStar,  Linux  TCP/IP  stack,  hostap  driver, 
and  the  SMC  WLAN  card  are  managed  in  the  first-in-first-out 
(FIFO)  manner.  Therefore,  as  long  as  we  make  sure  that  each 
data  transmission  from  the  LOF  process  can  be  encapsulated  in 
a  single  MAC  frame,  each  MAC  feedback  can  be  mapped  with 
the  corresponding  data  transmission  if  there  is  no  loss  of  MAC 
feedback. 

Nevertheless,  we  find  that,  under  stressful  conditions,  MAC 
feedback  may  get  lost  in  two  ways: 

•  A  MAC  feedback  will  be  dropped  in  netlink  sockets  if  the 
socket  buffer  overflows. 

•  If  there  is  no  valid  ARP  (Address  Resolution  Protocol) 
entry  regarding  the  unicast  destination,  a  data  packet  is 
dropped  at  the  IP  layer  (without  informing  the  application 
layer)  before  even  getting  to  the  hostap  driver,  which  means 
that  no  MAC  feedback  will  be  generated  and  thus  “lost”. 

To  deal  with  possible  loss  of  MAC  feedback,  LOF  adopts  the 
following  two  mechanisms: 

•  To  avoid  buffer  overflow  at  netlink  sockets,  LOF  enforces 
flow  control  within  a  node  by  enforcing  an  upper  bound 


on  the  number  of  data  transmissions  whose  MAC  feedback 
has  not  come  back.  (This  upper  bound  is  set  to  7  in  our 
experiments.) 

•  After  each  data  transmission,  LOF  checks  the  kernel  ARP 
table  to  see  if  there  is  a  valid  entry  for  the  destination  of  this 
unicast  packet.  In  this  way,  LOF  is  able  to  decide  whether 
a  MAC  feedback  will  ever  come  back  and  act  accordingly. 

Via  the  stress  tests  in  both  testbeds  and  outdoor  deployment,  we 
find  that  the  above  mechanisms  guarantee  the  reliable  delivery 
of  MAC  feedback. 

We  implement  LOF  at  user-space  for  the  sake  of  safety  and 
easy  maintenance.  As  a  part  of  our  future  work,  we  are  explor¬ 
ing  implementing  LOF  in  kernel  space  to  see  if  the  process  of 
reliably  fetching  MAC  feedback  can  be  simplified. 

Reliable  transport.  MAC  feedback  helps  not  only  in  link  qual¬ 
ity  estimation  but  also  in  reliable  data  transport.  For  example, 
upon  detecting  a  failed  transmission  via  the  MAC  feedback,  a 
node  can  retransmit  the  failed  packet  via  a  new  next-hop  for¬ 
warder.  On  the  other  hand,  the  transmission  status  carried  in 
a  MAC  feedback  only  reflects  the  reliability  at  the  MAC  layer. 
To  guarantee  end-to-end  reliability,  we  need  to  make  sure  that 
packet  delivery  is  reliable  at  layers  above  MAC:  First,  we  need 
to  guarantee  the  liveness  of  the  LOF  routing  process,  which  is 
enabled  by  the  EmStar  process  monitoring  facility  emrun  in  our 
current  implementation;  Second,  the  sender  of  a  packet  transmis¬ 
sion  guarantees  that  the  packet  is  received  by  the  hostap  driver, 
using  the  transmission  status  report  from  EmStar;  Third,  sender- 
side  flow  control  guarantees  that  there  is  no  queue  overflow  at 
the  receiver  side. 

Node  mobility.  Given  that  nodes  in  most  sensor  networks  are 
static,  LOF  is  not  designed  to  support  high  degree  of  mobility. 
Nevertheless,  LOF  can  deal  with  infrequent  movement  of  nodes 
in  the  following  simple  manner: 

•  If  the  base  station  moves,  the  new  location  of  the  base  sta¬ 
tion  is  diffused  across  the  network; 

•  If  a  node  other  than  the  base  station  moves,  it  first  broadcast 
M  copies  of  hello-withdrawal  packets,  then  it  restarts  its 
routing  process. 

(Note  that  a  node  can  detect  the  movement  of  itself  with  the  help 
of  a  GPS  device.) 

Neighbor-table  size  control.  Compared  with  Berkeley  motes, 
Stargates  have  relatively  large  memory  and  disk  size  (e.g.,  64MB 
RAM  and  32MB  flash  disk).  Therefore,  we  adopt  a  very  simple 
method  of  neighbor-table  size  control:  keeping  the  best  next-hop 
forwarders  according  to  their  ranks.  In  our  experiments,  we  set 
the  maximum  neighbor  table  size  as  20.  A  more  detailed  study 
of  the  best  neighborhood  management  scheme  for  Stargates  is 
beyond  the  scope  of  this  paper. 


5  Experimental  evaluation 

Via  testbeds  and  field  deployment,  we  experimentally  evalu¬ 
ate  the  design  decisions  and  the  performance  of  LOF.  First,  we 
present  the  experiment  design;  then  we  discuss  the  experimental 
results. 


11 


5.1  Experiment  design 

Network  setup.  In  our  indoor  testbed  as  shown  in  Figure  2,  we 
let  the  Stargate  at  the  left-bottom  corner  of  the  grid  be  the  base 
station,  to  which  the  other  Stargates  need  to  find  routes.  Then, 
we  let  the  Stargate  S  at  the  upper-right  corner  of  the  grid  be  the 
traffic  source.  S  sends  packets  of  length  1200  bytes  according  to 
the  ExScal  event  trace  as  discussed  in  Section  2.1  and  Figure  3. 
For  each  protocol  we  study,  S  simulates  50  event  runs,  with  the 
interval  between  consecutive  runs  being  20  seconds.  Therefore, 
for  each  protocol  studied,  950  (i.e.,  50  x  19)  packets  are  gener¬ 
ated  at  S. 

We  have  tested  scenarios  of  multiple  senders  and  periodic  traf¬ 
fic,  and  EOF  has  also  been  used  in  the  backbone  network  of  ExS¬ 
cal.  We  discuss  them  in  Section  5.3. 

Protocols  studied.  We  study  the  performance  of  EOF  in  com¬ 
parison  with  that  of  beacon-based  routing,  where  the  latest  de¬ 
velopment  is  represented  by  ETX  [8,  21]  and  PRD  [19]:  (For  con¬ 
venience,  we  do  not  differentiate  the  name  of  a  routing  metric  and  the  protocol 
implementing  it.) 

•  ETX:  expected  transmission  count.  It  is  a  type  of 
geography-unaware  routing  where  a  node  adopts  a  route 
with  the  minimum  ETX  value.  Since  the  transmission  rate 
is  fixed  in  our  experiments,  ETX  routing  also  represents  an¬ 
other  metric  ETT  [10],  where  a  route  with  the  minimum 
expected  transmission  time  is  used. 

•  PRD:  product  of  packet  reception  rate  and  distance  tra¬ 
versed  toward  the  destination.  Unlike  ETX,  PRD  is 
geography-based.  In  PRD,  a  node  selects  as  its  next-hop 
forwarder  the  neighbor  with  the  maximum  PRD  value. 
In  its  design  and  analysis,  PRD  assumes  geographic- 
uniformity,  that  the  hops  in  any  route  have  approximately 
the  same  geographic  length. 

Both  ETX  and  PRD  use  broadcast  beacons  in  estimating  the  re¬ 
spective  routing  metrics.  Since  it  has  been  shown  that  ETX  and 
PRD  perform  better  than  protocols  based  on  metrics  such  as  RTT 
(round-trip-time)  and  hop-count  [9,  19],  we  do  not  study  those 
protocols  in  this  paper. 

To  verify  some  important  design  decisions  of  LOF,  we  also 
study  different  versions  of  LOF  as  follows: 

•  L-hop:  assumes  geographic -uniformity,  and  thus  uses  met¬ 
ric  ELR,  as  specified  by  formula  (6),  instead  of  ELD; 

•  L-ns:  does  not  use  the  method  of  probabilistic  neighbor 
switching; 

•  L-sd:  considers,  in  probabilistic  neighbor  switching,  the 
neighbors  that  have  been  marked  as  dead; 

•  L-se:  performs  probabilistic  neighbor  switching  after  every 
packet  transmission. 

For  easy  comparison,  we  have  implemented  all  the  protocols 
mentioned  above  in  EmStar  [2],  a  software  environment  for  de¬ 
veloping  and  deploying  wireless  sensor  networks. 

Evaluation  criteria.  Reliability  is  one  critical  concern  in  con- 
vergecast.  Using  the  techniques  of  reliable  transport  discussed 
in  Section  4.5,  all  the  protocols  guarantee  100%  packet  delivery 
according  to  our  experiments.  Therefore,  we  compare  protocols 
in  metrics  other  than  reliability  as  follows: 

•  End-to-end  MAC  latency:  the  sum  of  the  MAC  latency 


spent  at  each  hop  of  a  route.  This  reflects  not  only  the  deliv¬ 
ery  latency  but  also  the  throughput  available  via  a  protocol 
[8,10], 

•  Energy  efficiency:  energy  spent  in  delivering  a  packet  to  the 
base  station. 

•  Route  stability:  the  number  as  well  as  the  degree  of  route 
changes,  and  the  stability  of  end-to-end  packet  delivery. 


5.2  Experimental  results 

MAC  latency.  Using  boxplots6.  Figure  17  shows  the  end-to-end 


Figure  17:  End-to-end  MAC  latency 

MAC  latency,  in  milliseconds,  for  each  protocol.  The  average 
end-to-end  MAC  latency  in  both  ETX  and  PRD  is  around  3  times 
that  in  LOF,  indicating  the  advantage  of  both  the  data-driven  link 
quality  estimation  and  the  decision  of  not  assuming  geographic 
uniformity.  The  MAC  latency  in  LOF  is  also  less  than  that  of  the 
other  versions  of  LOF,  showing  the  importance  of  using  the  right 
routing  metric  and  neighbor  switching  technique. 

To  explain  the  above  observation.  Figures  18,  19,  20,  and  21 
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ETX  PRD  LOF  L-hop  L-ns  L-sd  L-s 


Figure  18:  Number  of  hops  in  a  route 

show  the  route  hop  length,  per-hop  MAC  latency,  average  per- 
hop  geographic  distance,  and  the  coefficient  of  variation  (COV) 
of  per-hop  geographic  distance.  Even  though  the  average  route 
hop  length  and  per-hop  geographic  distance  in  ETX  are  approx¬ 
imately  the  same  as  those  in  LOF,  the  average  per-hop  MAC 
latency  in  ETX  is  about  3  times  that  in  LOF,  which  explains  why 
the  end-to-end  MAC  latency  in  ETX  is  about  3  times  that  in  LOF. 

6Boxplot  is  a  nice  tool  for  describing  the  distribution  of  a  data  sample: 

•  The  lower  and  upper  lines  of  the  “box”  are  the  25th  and  75th  percentiles  of  the  sam¬ 
ple.  The  distance  between  the  top  and  bottom  of  the  box  is  the  interquartile  range. 

•  The  line  in  the  middle  of  the  box  is  the  sample  median. 

•  The  “whiskers”,  lines  extending  above  and  below  the  box,  show  the  extent  of  the  rest 
of  the  sample.  If  there  is  no  outlier,  the  top  of  the  upper  whisker  is  the  maximum 
of  the  sample,  and  the  bottom  of  the  lower  whisker  is  the  minimum.  An  outlier  is  a 
value  that  is  more  than  1.5  times  the  interquartile  range  away  from  the  top  or  bottom 
of  the  box.  An  outlier,  if  any,  is  represented  as  a  plus  sign. 

•  The  notches  in  the  box  shows  the  95%  confidence  interval  for  the  sample  median. 
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Figure  19:  Per-hop  MAC  latency 


Figure  22:  Number  of  unicast  transmissions  per  packet  received 


Figure  20:  Average  per-hop  geographic  distance 


Prism2.5  chipset  which  does  not  expose  the  information  on  the 
number  of  retries  of  a  unicast  transmission.  Figure  22  does  not 
represent  the  actual  number  of  bytes  sent.  Nevertheless,  given 
Figure  19  and  the  fact  that  MAC  latency  and  energy  consumption 
are  positively  related  (as  discussed  in  Section  3.1),  the  above 
observation  on  the  relative  energy  efficiency  among  the  protocols 
still  holds. 

To  explain  the  above  observation.  Figure  23  shows  the  num- 


Figure  23:  Number  of  failed  unicast  transmissions 


Figure  21:  COV  of  per-hop  geographic  distance  in  a  route 

In  PRD,  both  the  average  route  hop  length  and  the  average  per- 
hop  MAC  latency  is  about  twice  that  in  LOF. 

From  Figure  2 1 ,  we  see  that  the  COV  of  per-hop  geographic 
distance  is  as  high  as  0.4305  in  PRD  and  0.2754  in  L-hop.  There¬ 
fore,  the  assumption  of  geographic  uniformity  is  invalid,  which 
partly  explains  why  PRD  and  L-hop  do  not  perform  as  well  as 
LOF.  Moreover,  the  fact  that  the  COV  value  in  LOF  is  the  largest 
and  that  LOF  performs  the  best  tend  to  suggest  that  the  network 
state  is  heterogeneous  at  different  locations  of  the  network. 

Energy  efficiency.  Given  that  beacons  are  periodically  broad¬ 
casted  in  ETX  and  PRD,  and  that  beacons  are  rarely  used  in  LOF, 
it  is  easy  to  see  that  more  beacons  are  broadcasted  in  ETX  and 
PRD  than  in  LOF  Therefore,  we  focus  our  attention  only  on 
the  number  of  unicast  transmissions  required  for  delivering  data 
packets  to  the  base  station,  rather  than  on  the  broadcast  overhead. 
To  this  end,  Figure  22  shows  the  number  of  unicast  transmissions 
averaged  over  the  number  packets  received  at  the  base  station. 
The  number  of  unicast  transmissions  per  packet  received  in  ETX 
and  PRD  is  1.49  and  2.37  times  that  in  LOF  respectively,  show¬ 
ing  again  the  advantage  of  data-driven  instead  of  beacon-based 
link  quality  estimation.  The  number  of  unicast  transmissions  per 
packet  received  in  LOF  is  also  less  than  that  in  the  other  ver¬ 
sions  of  LOF.  For  instance,  the  number  of  unicast  transmissions 
in  L-hop  is  2.89  times  that  in  LOF 

Given  that  the  SMC  WLAN  card  in  our  testbed  uses  Intersil 


ber  of  failed  unicast  transmissions  for  the  950  packets  generated 
at  the  source.  The  number  of  failures  in  ETX  and  PRD  is  1112 
and  786  respectively,  yet  there  are  only  5  transmission  failures 
in  LOF  Also,  there  are  711  transmission  failures  in  L-hop.  To¬ 
gether  with  Figures  20  and  5(b),  we  see  that  there  exist  reliable 
long  links,  yet  only  LOF  tends  to  find  them  well:  ETX  also  uses 
long  links,  but  they  are  not  reliable;  L-ns  uses  reliable  links,  but 
they  are  relatively  shorter. 

Besides  degenerating  energy  efficiency,  transmission  failures 
also  increase  queue  accumulation,  which  can  lead  to  reduction 
in  network  throughput.  Figure  24  shows  the  maximum  of  the 


Figure  24:  Maximum  average  queue  length 

average  queue  length  at  the  nodes  involved  in  packet  delivery. 
The  maximum  queue  length  in  ETX  and  PRD  is  12.64  and  5.22 
times  that  in  LOF  respectively.  The  maximum  queue  length  in 
L-hop  is  also  5.22  times  that  in  LOF,  again  showing  the  negative 
impact  of  the  invalid  assumption  —  geographic  uniformity. 
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Route  stability.  Figure  25  shows  the  average  number  of  route 


Figure  25:  Average  number  of  route  changes  per  node 

changes  at  each  node.  For  readability  in  spite  of  the  sharp  dif¬ 
ference  in  the  values  across  protocols,  we  present  the  common 
logarithm  (i.e.,  base  10)  of  the  values  along  the  y-axis.  We  see 
that  the  average  number  of  route  changes  in  ETX  and  PRD  is  2 
orders  of  magnitude  greater  than  that  in  LOF.  As  a  result,  packets 
tend  to  be  delivered  in  order  in  LOF  but  not  in  ETX  and  PRD,  as 
shown  in  Figure  26  where  the  reorder  distance  of  a  packet  po  is 
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Figure  26:  Packet  reorder  distance 

the  number  of  packets  that  are  generated  later  than  po  but  reach 
the  base  station  earlier  than  Pq. 

To  understand  how  route  changes,  we  measure  the  degree  of 
route  changes  and  how  the  hop-length  of  routes  change.  The 
degree  of  route  change  is  measured  as  follows: 

•  0:  the  route  taken  by  a  packet  is  the  same  as  that  taken  by 
the  previous  packet; 

•  -1:  the  route  taken  by  a  packet  is  different  from  that  taken 
by  the  previous  packet,  but  they  are  of  equal  hop  length; 

•  -2:  the  route  taken  by  a  packet  is  longer,  in  hop-length,  than 
that  taken  by  the  previous  packet; 

•  -3:  the  route  taken  by  a  packet  is  shorter,  in  hop-length,  than 
that  taken  by  the  previous  packet. 

Due  to  space  limitations,  we  only  present,  in  Figure  27,  the  time 
series  of  the  hop-length  and  the  degree  of  route  change  for  pro¬ 
tocols  ETX,  PRD,  LOF,  and  L-hop.  LOF  seldom  changes  route; 
yet  route  changes  frequently  in  ETX  and  PRD,  even  when  the 
routes  are  of  equal  hop-length. 

5.3  Other  experiments 

Besides  the  scenario  of  1  source  event  traffic  which 
we  discussed  in  detail  in  the  last  subsection,  we  have 
performed  experiments  where  the  Stargate  at  the  upper- 
right  corner  and  its  two  immediate  grid-neighbors  simul¬ 
taneously  generate  packets  from  the  ExScal  traffic  trace. 


(a)  ETX  (b)  PRD 


(c)  LOF  (d)  L-hop 


Figure  27:  Time  series  of  route  changes 


We  have  also  experimented 
with  periodic  traffic  where  1  or 
3  Stargates  (same  as  those  in 
the  case  of  event  traffic)  gen¬ 
erate  1,000  packets  each,  with 
each  packet  being  1200-byte 
long  and  the  inter-packet  inter¬ 
val  being  500  milliseconds.  In 
these  experiments,  we  have  ob¬ 
served  similar  patterns  in  the 
relative  protocol  performance 
as  those  in  the  case  of  1  source 
event  traffic.  For  conciseness, 
we  only  present  the  end-to-end 
MAC  latency  for  these  three 
cases,  as  shown  in  Figure  28. 

With  its  well-tested  perfor¬ 
mance,  the  implementation  of 
LOF  has  been  used  in  the  field 
sensor  network  project  ExS¬ 
cal  [5]  where  203  Stargates 
and  985  XSM  motes  are  de¬ 
ployed  in  an  area  of  1260 
meters  by  288  meters.  The 
203  Stargates  form  the  back¬ 
bone  network  of  ExScal  to 
support  reliable  and  real-time 
communication  among  the  985 
XSM  motes  deployed  for  target 
detection,  classification,  and 
tracking.  LOF  has  successfully 
guaranteed  reliable  and  real¬ 
time  convergecast  from  any 
number  of  non-base  Stargates 
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Figure  28:  End-to-end  MAC 
latency 
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to  the  base  station  in  ExScal,  showing  not  only  the  performance 
of  the  protocol  but  also  the  stability  of  its  implementation. 


6  Related  work 

There  is  a  rich  literature  on  routing  in  ad  hoc  and  wireless  net¬ 
works.  In  this  section,  we  only  review  those  related  most  closely 
to  LOF. 

Link  properties  in  802.11b  mesh  networks  and  dense  wire¬ 
less  sensor  networks  have  been  well  studied  in  [6],  [17],  and 
[23],  They  have  observed  that  wireless  links  assume  complex 
properties,  such  as  wide-range  non-uniform  packet  delivery  rate 
at  different  distances,  loose  correlation  between  distance  and 
packet  delivery  rate,  link  asymmetry,  and  temporal  variations. 
Our  study  on  link  properties  complements  the  existing  works  by 
focusing  on  the  differences  between  broadcast  and  unicast  link 
properties,  as  well  as  the  impact  of  interference  pattern  on  the 
differences. 

Differences  between  broadcast  and  unicast  and  their  impact 
on  the  performance  of  AODV  have  been  discussed  in  [18]  and 
[7].  Our  work  complements  theirs  by  experimentally  study  the 
differences  as  well  as  the  impact  of  environment,  distance,  and 
interference  pattern  on  the  differences,  which  were  not  the  fo¬ 
cus  of  [18]  and  [7].  [7]  mentioned  the  difficulty  of  getting  MAC 
feedback  and  thus  sticked  to  the  method  of  beacon-used  link  es¬ 
timation.  Our  work  complements  it  by  developing  techniques  for 
reliably  fetching  MAC  feedback,  which  build  the  foundation  for 
beacon-free  link  estimation  as  well  as  routing.  To  improve  the 
performance  of  AODV,  [18]  and  [7]  also  discussed  reliability- 
based  mechanisms  (e.g.,  SNR-based  ones)  for  blacklisting  bad 
links.  Since  it  has  been  shown  that  reliability-based  blacklisting 
does  not  perform  as  well  as  ETX  [11,  8,  21],  we  do  not  directly 
compare  LOF  to  [18]  and  [7],  instead  we  compare  LOF  to  ETX. 

Recently,  great  progress  has  been  made  regarding  routing  in 
wireless  sensor  networks  as  well  as  in  mesh  networks.  Rout¬ 
ing  metrics  such  as  ETX  [8,  21]  and  ETT/WCETT  [10]  have 
been  proposed  and  shown  to  perform  well  in  real-world  wire¬ 
less  networks  [9],  The  geography-based  metric  PRD  [19]  has 
also  been  proposed  for  energy-efficient  routing  in  wireless  sen¬ 
sor  networks.  Nevertheless,  unicast  link  properties  were  still 
estimated  based  on  those  of  broadcast  beacons  in  these  works, 
and  [19]  did  not  experimentally  verify  the  assumption  of  “geo¬ 
graphic  uniformity”  —  that  the  hops  in  any  route  have  approx¬ 
imately  the  same  geographic  length.  Our  work  differs  from  the 
existing  approaches  by  experimentally  demonstrating  the  diffi¬ 
culty  of  precisely  estimating  unicast  link  properties  via  those  of 
broadcast  beacons,  experimentally  invalidating  the  assumption 
of  geographic  uniformity,  and  proposing  the  beacon-free  proto¬ 
col  LOF  where  unicast  link  properties  are  estimated  via  the  data 
traffic  itself  and  geographic  uniformity  is  not  assumed.  Another 
side  result  of  our  work  is  the  comparison  between  the  geography- 
unaware  ETX  routing  and  the  geography-based  PRD  routing, 
which  has  not  been  done  in  the  literature. 

The  problem  of  local  maximum  or  geographic  void  has  been 
dealt  with  in  routing  protocols  such  as  GPSR  [16].  We  have 
not  considered  this  problem  in  LOF,  since  it  is  orthogonal  to  our 
major  concern  —  data-driven  link  quality  estimation  as  well  as 


routing.  As  a  part  of  our  future  work,  we  plan  to  incorporate 
techniques  developed  by  GPSR  into  the  implementation  of  LOF. 

7  Concluding  remarks 

Via  experiments  in  testbeds  of  802.11b  networks,  we  have 
demonstrated  the  weakness  of  beacon-based  link  quality  estima¬ 
tion  as  well  as  routing.  We  have  also  shown  that  the  assumption 
of  geographic  uniformity  is  invalid  in  geographic  routing. 

To  address  the  issues,  we  have  modified  the  Linux  kernel  and 
hostap  WLAN  driver  to  provide  feedback  on  the  MAC  latency  as 
well  as  the  status  of  every  unicast  transmission,  and  we  have  built 
system  software  for  reliably  fetching  MAC  feedbacks.  Based 
on  theses  system  facilities,  we  have  demonstrated  the  feasibility 
of  beacon-free  routing  by  designing  protocol  LOF.  It  uses  three 
main  techniques  for  link  quality  estimation  and  route  selection: 
initial  sampling,  data-driven  adaptation,  and  probabilistic  neigh¬ 
bor  switching.  Not  assuming  geographic  uniformity,  LOF  uses 
the  locally  measurable  routing  metric  ELD,  the  expected  MAC 
latency  per  unit-distance  toward  the  destination.  With  its  well 
tested  performance  and  implementation,  LOF  has  been  success¬ 
fully  used  to  support  convergecast  in  the  backbone  network  of 
ExScal,  where  203  Stargates  have  been  deployed  in  an  area  of 
1260  meters  by  288  meters. 

Besides  saving  energy  by  avoiding  periodic  beaconing,  the 
beacon-free  nature  of  LOF  facilitates  greater  extent  of  energy 
conservation,  because  LOF  does  not  require  a  node  to  be  awake 
unless  it  is  generating  or  forwarding  data  traffic.  The  beacon-free 
nature  of  LOF  also  helps  in  enhancing  network  security,  since 
the  network  is  less  exposed.  More  detailed  study  of  the  impact 
of  beacon-free  routing  on  energy  efficiency  and  security  is  a  part 
of  our  future  work. 

Acknowledgment 

We  thank  Vinayak  Naik  and  Emre  Ertin  for  their  help  in  the  dis¬ 
cussion  and  experimentation.  We  also  appreciate  the  help  from 
UCLA  EmStar  team  for  their  help  in  answering  questions  re¬ 
garding  EmStar.  The  help  and  support  from  our  ExScal  team  are 
always  appreciated. 

References 

[1]  Crossbow  technology  inc.  http://www.xbow.com/. 

[2]  EmStar:  Software  for  wireless  sensor  networks. 

http://cvs.cens.ucla.edu/emstar/. 

[3]  Linux  WLAN  driver  hostap.  http://hostap.epitest.fi/. 

[4]  Wireless  LAN  medium  access  control  (MAC)  and  physical  layer  (PHY) 
specifications.  In  ANSI/IEEE  Std  802.11.  1999. 

[5]  Exscal  project,  http://www.cse.ohio-state.edu/exscal,  2004. 

[6]  D.  Aguayo,  J.  Bicket,  S.  Biswas,  G.  Judd,  and  R.  Morris.  Link-level  mea¬ 
surements  from  an  802.11b  mesh  network.  In  ACM  SIGCOMM,  pages 
121-132,  2004. 

[7]  I.  Chakeres  and  E.  Belding-Royer.  The  utility  of  hello  messages  for  deter¬ 
mining  link  connectivity.  In  WPMC,  2002. 

[8]  D.  S.  J.  D.  Couto,  D.  Aguayo,  J.  Bicket,  and  R.  Morris.  A  high-throughput 
path  metric  for  multi-hop  wireless  routing.  In  ACM  MobiCom,  pages  134— 
146,  2003. 

[9]  R.  Draves,  J.  Padhye,  and  B.  Zill.  Comparison  of  routing  metrics  for  static 
multi-hop  wireless  networks.  In  ACM  SIGCOMM,  pages  133-144,  2004. 


15 


[10]  R.  Draves,  J.  Padhye,  and  B.  Zill.  Routing  in  multi-radio,  multi-hop  wire¬ 
less  mesh  networks.  In  ACM  MobiCom,  pages  114-128,  2004. 

[11]  O.  Gnawali,  M.  Yarvis,  J.  Heidemann,  and  R.  Govindan.  Interaction  of 
retransmission,  blacklisting,  and  routing  metrics  for  reliability  in  sensor 
network  routing.  In  IEEE  SECON,  pages  34-43,  2004. 

[12]  T.  Herbert.  The  Linux  TCP/IP  Stack:  Networking  for  Embedded  Systems. 
Charles  River  Media,  2004. 

[13]  F.  Hillier  and  G.  Lieberman.  Introduction  to  Operations  Research. 
McGraw-Hill,  2001. 

[14]  M.  Hollander.  Nonparametric  statistical  methods.  Wiley,  1999. 

[15]  R.  Jain.  The  Art  of  Computer  Systems  Performance  Analysis.  John  Wiley 
&  Sons,  Inc.,  1991. 

[16]  B.  Karp  and  H.  T.  Kung.  GPSR:  Greedy  perimeter  stateless  routing  for 
wireless  networks.  In  ACM  MobiCom,  pages  243-254,  2000. 

[17]  D.  Kotz,  C.  Newport,  and  C.  Elliott.  The  mistaken  axioms  of  wireless- 
network  research.  Technical  Report  TR2003-467,  Dartmouth  College, 
Computer  Science,  July  2003. 

[18]  H.  Lundgren,  E.  Nordstrom,  and  C.  Tschudin.  Coping  with  communication 
gray  zones  in  ieee  802.11b  based  ad  hoc  networks.  In  ACM  WoWMoM, 
pages  49-55,  2002. 

[19]  K.  Seada,  M.  Zuniga,  A.  Helmy,  and  B.  Krishnamacari.  Energy-efficient 
forwarding  strategies  for  geographic  routing  in  lossy  wireless  sensor  net¬ 
works.  In  ACM  SenSys,  2004. 

[20]  R.  Thisted.  Elements  of  statistical  computing.  Chapman  &  Hall,  Ltd.,  1988. 

[21]  A.  Woo,  T.  Tong,  and  D.  Culler.  Taming  the  underlying  challenges  of 
reliable  multihop  routing  in  sensor  networks.  In  ACM  SENSYS,  pages  14— 
27,  2003. 

[22]  H.  Zhang,  A.  Arora,  Y.  R.  Choi,  and  M.  Gouda.  Reliable  bursty  converge- 
cast  in  wireless  sensor  networks.  In  ACM  MobiHoc,  2005. 

[23]  J.  Zhao  and  R.  Govindan.  Understanding  packet  delivery  performance  in 
dense  wireless  sensor  networks.  In  ACM  SenSys,  pages  1-13,  2003. 


16 


